Pedro Moreno-Sanchez [ARCHIVE] on Nostr: 📅 Original date posted:2021-02-09 📝 Original message: Hi Nadav, You are right ...
📅 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>;
📝 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>;