Hi Andrés, > Am I correct in understanding that this is a proposal to change the spec (maybe add a new BOLT) so that all lightning implementations can try to support this feature.
Yes, the proposal relies on the use of PTLCs in place of HTLCs which is a popular change that will (hopefully) be brought about by Taproot. It is worth noting that this change is not specific to this protocol and that only the end nodes (buyer and seller) would need any special code in order to execute these contracts if the underlying Lightning Network was using PTLCs. > If the above is true, then I'm wondering: could a Lightning-based escrow system be implemented that doesn't require to modify the existing implementations? Maybe if we simplify the requirements a bit? Like, removing the "Escrow only learns of dispute cases, never learns non-dispute case" aspect? That is, the third-party S always knows about an escrow between A and B taking place. At a high level, what is required here is that the payment goes through iff [Seller AND (Buyer OR Escrow)] agree to it. Lifting restrictions so that the Escrow is allowed to be more interactive can allow the Buyer and Escrow to do an interactive shared secret generation and this secret could then be used in a spontaneous payment to the Seller (meaning the payment hash is generated by the Buyer and not the Seller) and then the Seller would have to obtain a ZKP from the Escrow that the payment hash is the hash of a secret known to the Escrow. If all of this were done, then the Seller could execute given the shared secret from either the Buyer or the Escrow. Of note, another downside to this scheme beyond Escrow involvement is that there is no proof of payment/reciept over the Lightning Network for this payment because it is a spontaneous payment. Like ZmnSCPxj's proposal, this would only require special code for the "end nodes" (Buyer and Seller) and the underlying HTLC-based lightning network would require no changes. Also note that this scheme relies on the existence of a Zero Knowledge Proof of Knowledge (ZKPoK) of a hash which is not a trivial piece of work but certainly do-able. Hi Pedro, I actually did have a question for you about Virtual Channels: The first time I read the paper it struck me that while on the surface things look pretty nice for the virtual channel participants, the intermediary has to lock up a lot of collateral (in total, the size of the channel) in order to enable this and subsequently this channel could stay open for a very long time. As such, to the intermediary this seems very similar to having to route a (potentially very large) hodl HTLC which means they will be charging a very large fee for both the setup and the duration of the channel. Because of this, I'm having trouble thinking of almost any use cases where this is preferable to just routing payments the normal way other than if the in-between node is not reliable and there are no other cheap routes (in which case it might be worth it to pay a premium). Did you or your colleagues have other use cases in mind? And have you done any fee analysis for this scheme? Best, Nadav On Mon, Feb 8, 2021 at 2:43 AM Pedro Moreno-Sanchez < pedrorechezmailingli...@gmail.com> wrote: > Hello, > > While reading this thread I realized that my colleagues and I have been > working on a construction called “Bitcoin-compatible Virtual Channels” [1] > that, at a first glance, highly resembles the use case and requirements > that you put forward in this thread. In a nutshell, a Virtual Channel is > built on top of two payment channels and use them to construct its own > “funding transaction”. Imagine that Buyer and Seller do not have a payment > channel between them, but they both have a payment channel with a common > node (e.g., Escrow in your example). Alice and Bob can create a Virtual > Channel between them using fundings from both: channel Alice-Escrow and > channel Escrow-Bob. After created, the Virtual Channel offers the same > functionality as a direct payment channel between Alice and Bob (i.e., > Escrow is no longer involved for payments). Our construction makes sure > that no party losses funds when the Virtual Channel needs to be closed > (either when Alice and Bob collaborate or any of the 3 parties cheat). > > This construction is compatible with the current Bitcoin script (e.g., > taproot is not required although perhaps useful when available) and with > the Lightning Network. In the paper, we describe our construction assuming > that a payment-channel follows the design in “Generalized > Bitcoin-Compatible Channels” [2], however the Virtual Channel construction > can seamlessly work using the current Lightning payment channels. > > I would be glad to hear any feedback that you may have. > > Cheers, > Pedro Moreno-Sanchez > > == > > [1] https://eprint.iacr.org/2020/554 > [2] https://eprint.iacr.org/2020/476.pdf > > > On Feb 8, 2021, at 9:09 AM, Andrés G. Aragoneses <kno...@gmail.com> > wrote: > > > > Hey ZmnSCPxj, > > > > Am I correct in understanding that this is a proposal to change the spec > (maybe add a new BOLT) so that all lightning implementations can try to > support this feature. > > > > If the above is true, then I'm wondering: could a Lightning-based escrow > system be implemented that doesn't require to modify the existing > implementations? Maybe if we simplify the requirements a bit? Like, > removing the "Escrow only learns of dispute cases, never learns non-dispute > case" aspect? That is, the third-party S always knows about an escrow > between A and B taking place. > > > > I understand that the above requirement is a good to have, but if > removing it allows a simpler version of escrow be implemented, then at > least there could be an interim solution for non-custodial exchanges to > start adopting this (otherwise they have to resort to custodial-based > escrows, which is worse than lacking the escrow privacy brought by the > requirement above). > > > > Thanks > > _______________________________________________ > > 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 >
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
