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.dziem...@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


_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Reply via email to