Pedro Moreno-Sanchez [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2021-02-08 to 2021-02-11
💬 Posted a total of 3 messages
📚 Participated in the following categories: Lightning-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-09 13:01:59

- reply

📅 Original date posted:2021-02-11
📝 Original message:
> On Feb 11, 2021, at 6:31 AM, ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
>
> Good morning Pedro,
>
>> Hi Nadav,
>>
>> You are right that the intermediary (i.e., Ingrid) needs to hold a certain amount of coins to allow the virtual channel between Alice and Bob. Some comments here:
>> - The protocol makes sure that Ingrid will get paid whatever fee she decides to charge for the service of creating a virtual channel. Note that Ingrid does not have the guarantee that enough payments would be routed through her node to gain the same fee in the same amount of time.
>
> Have not examined this deeply, but what happens if any of the *actual* Alice-Ingrid or Ingrid-Bob channels are forced unilaterally onchain before the purported lifetime of the virtual channel?
As a safe fallback, the protocol gives time to Ingrid (or Bob depending on the case) to put the other channel onchain before the punishment can be triggered.
>
> Regards,
> ZmnSCPxj

2023-06-09 13:01:58

- reply

📅 Original date posted:2021-02-09
📝 Original message:
Hi Nadav,
You are right that the intermediary (i.e., Ingrid) needs to hold a certain amount of coins to allow the virtual channel between Alice and Bob. Some comments here:
- The protocol makes sure that Ingrid will get paid whatever fee she decides to charge for the service of creating a virtual channel. Note that Ingrid does not have the guarantee that enough payments would be routed through her node to gain the same fee in the same amount of time.
- If Ingrid is afraid that her coins will hold too long, one of the two modes in our construction for virtual channels offers the possibility for Ingrid to close the virtual channel at any time and get the locked coins back (plus the fee).
- On the other hand, imagine that Ingrid charges “x” as fee. Alice and Bob would be interested in opening a virtual channel if they plan to do a number of payments between them such that the total fee they would pay would be higher than “x”. (We have a more elaborated fee analysis at the end of the performance evaluation section in the paper).
We envision some use cases where virtual channels would be beneficial:
- Imagine Bob is a new provider of a web service (e.g., premium news or a premium music player) that charges for each new/song that is downloaded. Alice, who has previously created all the channels that she is willing/able to manage, still wants to try this new service. Alice could open a virtual channel with Bob to try out this service.
- Same situation as before, but Bob (a router) now offers wifi connection in exchange for micropayments.
- In general, any two-party computation between Alice and Bob that can be expressed in Bitcoin scripting language in a scenario where Alice and Bob do not share a payment channel yet.
And of course could be other use cases that we have not thought about yet. I am looking forward to hearing any proposal that people in this list might have.
Cheers,
Pedro.
> On 8 Feb 2021, at 20:49, Nadav Kohen <nadav at suredbits.com> wrote:
>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210209/bfd8277f/attachment.html>

2023-06-09 13:01:57

- reply

📅 Original date posted:2021-02-08
📝 Original message:
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