Nadav Kohen [ARCHIVE] on Nostr: 📅 Original date posted:2021-02-08 📝 Original message: Hi Andrés, > Am I ...
đź“… Original date posted:2021-02-08
đź“ť Original message:
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 <
pedrorechezmailinglists at 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 <knocte at 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 at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210208/89782223/attachment.html>;
đź“ť Original message:
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 <
pedrorechezmailinglists at 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 <knocte at 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 at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210208/89782223/attachment.html>;