Re: [Lightning-dev] Escrow Over Lightning?
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 > wrote: > > > > Hey ZmnSCPxj, > >
Re: [Lightning-dev] Pay-for-Elgamal-decryption-key and its application to Anonymous Credentials
(I have replied without changing the subject line byte mistake so I will reply again. sorry for spamming) > But I see the advantage of your idea. If a malicious credential server is > able to identify you somehow at the point of payment then they might want > to selectively steal your money while being honest with everyone else. > In your scheme, if you pay you get the credential and then since it is > anonymous it can't be distinguished from others when you go to claim whatever > it entails. > Is this the idea? Yes, And in case of a trustful exchange with LN, the malicious server does not even have to distinguish a user. The server can just choose one private channel that is connected to itself and decides to be dishonest to it. The victim has no way to prove that he did NOT receive a credential after payment. Even if the server acts completely honestly, the user may claim that they did not receive the credentials after payment. Other entities have no way to tell if the user has been fooled or they are just trying to undermine the reputation of the service. (In the case of credential presentation, it is easy to check if the server is acting honestly. Just run the blind-show protocol and check if the server acts expectedly. The blind-show can be run by anyone and the server has no way to distinguish which credential they received.) Thus I think making an exchange atomic in this way is necessary for a commercial application. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Pay-for-Elgamal-decryption-key and its application to Anonymous Credentials
(I have replied without changing the subject line so I will reply again. sorry for spamming) > But I see the advantage of your idea. If a malicious credential server is > able to identify you somehow at the point of payment then they might want > to selectively steal your money while being honest with everyone else. > In your scheme, if you pay you get the credential and then since it is > anonymous it can't be distinguished from others when you go to claim whatever > it entails. > Is this the idea? Yes, And in case of a trustful exchange with LN, the malicious server does not even have to distinguish a user. The server can just choose one private channel that is connected to itself and decides to be dishonest to it. The victim has no way to prove that he did NOT receive a credential after payment. Even if the server acts completely honestly, the user may claim that they did not receive the credentials after payment. Other entities have no way to tell if the user has been fooled or they are just trying to undermine the reputation of the service. (In the case of credential presentation, it is easy to check if the server is acting honestly. Just run the blind-show protocol and check if the server acts expectedly. The blind-show can be run by anyone and the server has no way to distinguish which credential they received.) Thus I think making an exchange atomic in this way is necessary for a commercial application. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Escrow Over Lightning?
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 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
Re: [Lightning-dev] Escrow Over Lightning?
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
