Cezary Dziemian [ARCHIVE] on Nostr: π Original date posted:2019-02-19 π Original message: Thanks for answer ...
π
Original date posted:2019-02-19
π Original message:
Thanks for answer ZMNSCPxj,
Sad to hear that you have anything non LN-related to do that has higher
priority.
What, can't this this be done in easier way? For example:
1. Payee provides fee limit along with with Invoice. This can be amount
percentage or absolute value in msats.
2. Payer in order to pay just finds route, that do not exceed limit from
invoice
3. Payer just pays invoice
Solution above do not solve all issues, but at least it is easy to
implement and can be provided quite fast. I think, this is quite important,
because right now I see a lot of services that just cover fee costs, what
makes it easy to steal. I'm afraid that sooner or later someone will use
this method to steal some funds, what undermines LN confidence.
Best regards,
Cezary Dziemian
pt., 15 lut 2019 o 06:40 ZmnSCPxj <ZmnSCPxj at protonmail.com> napisaΕ(a):
> Good morning Cezary,
>
> I have alluded to this issue before:
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-January/001826.html
> See "Withdrawing funds from a service".
>
> From my point-of-view, the proper solution would involve the payee
> providing one or more complete paths from the payer to the payee node.
> These will be provided as fully encrypted onions to the payer, providing
> the following benefits:
>
> 1. The payee knows exactly how much it will lose in fees, since it is the
> one providing the path.
> 2. The payer cannot correlate a particular user with its LN node,
> improving privacy.
> 3. The payer cannot bias the route towards other nodes it controls that
> happen, completely for no good reason, to charge high LN fees; the payee
> generates the route and controls its fees.
>
> The use-case is where the payer is a publicly-useable service (an exchange
> as you gave example to).
> In this case, the payer provides its node address to the user, but the
> user never provides its node address to the service.
>
> There is no spec yet, and I am too busy with other considerations to
> actually work on anything Lightning-related, but perhaps you can pick up
> this, and continue its development.
>
> We need:
>
> 1. Some standard of transporting multiple *encrypted* onions from the
> user (payee) to the service (payer).
> 2. Some implementation must provide some method of generating multiple
> routes from the user (payee) to the service (payer).
> Importantly, this must compute "forwards", i.e. a constant amount will
> be released by the payer, and the payee will take whatever value remains
> after fees.
> This is more difficult than it seems due to how LN fees are computed,
> unfortunately (it is based on the outgoing amount; while mathematically it
> is possible to just manipulate the equations, in practice roundoffs will be
> different in some edge cases between the "backwards" and "forwards"
> methods).
> In addition, the implementation needs to have some heuristic, i.e. if
> it finds a route that loses more than 1% of the value being paid
> (overrideable by the user), then it probably should reject that route and
> not provide it to the service (payer).
>
> In essence, this issue shows the "other side" of merchants, which is
> exchanges.
> Current LN is biased towards merchants: the merchant exposes its node ID
> (on the invoice it provides to the user).
> For exchanges, we need to perform a dual transformation, where the
> exchange exposes its node ID somehow (via a mechanism that does not yet
> exist).
>
> Regards,
> ZmnSCPxj
>
>
> Sent with ProtonMail Secure Email.
>
> βββββββ Original Message βββββββ
> On Thursday, February 14, 2019 10:06 PM, Cezary Dziemian <
> cezary.dziemian at gmail.com> wrote:
>
> > Hi,
> > Not sure if this topic was mentioned, but is there any plan to provide
> payment solution in witch Payee pay fee instead of payer?
> >
> > The issue I found is on our exchange, when user can withdraw funds using
> LN. If we don't know fee in advance, he can't just withdraw everything what
> he has. We can assume, that he can withdraw up to 99,5% of his funds, but
> it would be nice, if he can just withdraw everything and what he receives
> is just his funds minus fee.
> > Did you discussed this before?
> > Best Regards,
> > Cezary Dziemian
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190219/e501c3ef/attachment.html>;
π Original message:
Thanks for answer ZMNSCPxj,
Sad to hear that you have anything non LN-related to do that has higher
priority.
What, can't this this be done in easier way? For example:
1. Payee provides fee limit along with with Invoice. This can be amount
percentage or absolute value in msats.
2. Payer in order to pay just finds route, that do not exceed limit from
invoice
3. Payer just pays invoice
Solution above do not solve all issues, but at least it is easy to
implement and can be provided quite fast. I think, this is quite important,
because right now I see a lot of services that just cover fee costs, what
makes it easy to steal. I'm afraid that sooner or later someone will use
this method to steal some funds, what undermines LN confidence.
Best regards,
Cezary Dziemian
pt., 15 lut 2019 o 06:40 ZmnSCPxj <ZmnSCPxj at protonmail.com> napisaΕ(a):
> Good morning Cezary,
>
> I have alluded to this issue before:
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-January/001826.html
> See "Withdrawing funds from a service".
>
> From my point-of-view, the proper solution would involve the payee
> providing one or more complete paths from the payer to the payee node.
> These will be provided as fully encrypted onions to the payer, providing
> the following benefits:
>
> 1. The payee knows exactly how much it will lose in fees, since it is the
> one providing the path.
> 2. The payer cannot correlate a particular user with its LN node,
> improving privacy.
> 3. The payer cannot bias the route towards other nodes it controls that
> happen, completely for no good reason, to charge high LN fees; the payee
> generates the route and controls its fees.
>
> The use-case is where the payer is a publicly-useable service (an exchange
> as you gave example to).
> In this case, the payer provides its node address to the user, but the
> user never provides its node address to the service.
>
> There is no spec yet, and I am too busy with other considerations to
> actually work on anything Lightning-related, but perhaps you can pick up
> this, and continue its development.
>
> We need:
>
> 1. Some standard of transporting multiple *encrypted* onions from the
> user (payee) to the service (payer).
> 2. Some implementation must provide some method of generating multiple
> routes from the user (payee) to the service (payer).
> Importantly, this must compute "forwards", i.e. a constant amount will
> be released by the payer, and the payee will take whatever value remains
> after fees.
> This is more difficult than it seems due to how LN fees are computed,
> unfortunately (it is based on the outgoing amount; while mathematically it
> is possible to just manipulate the equations, in practice roundoffs will be
> different in some edge cases between the "backwards" and "forwards"
> methods).
> In addition, the implementation needs to have some heuristic, i.e. if
> it finds a route that loses more than 1% of the value being paid
> (overrideable by the user), then it probably should reject that route and
> not provide it to the service (payer).
>
> In essence, this issue shows the "other side" of merchants, which is
> exchanges.
> Current LN is biased towards merchants: the merchant exposes its node ID
> (on the invoice it provides to the user).
> For exchanges, we need to perform a dual transformation, where the
> exchange exposes its node ID somehow (via a mechanism that does not yet
> exist).
>
> Regards,
> ZmnSCPxj
>
>
> Sent with ProtonMail Secure Email.
>
> βββββββ Original Message βββββββ
> On Thursday, February 14, 2019 10:06 PM, Cezary Dziemian <
> cezary.dziemian at gmail.com> wrote:
>
> > Hi,
> > Not sure if this topic was mentioned, but is there any plan to provide
> payment solution in witch Payee pay fee instead of payer?
> >
> > The issue I found is on our exchange, when user can withdraw funds using
> LN. If we don't know fee in advance, he can't just withdraw everything what
> he has. We can assume, that he can withdraw up to 99,5% of his funds, but
> it would be nice, if he can just withdraw everything and what he receives
> is just his funds minus fee.
> > Did you discussed this before?
> > Best Regards,
> > Cezary Dziemian
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190219/e501c3ef/attachment.html>;